rootscan_03_DevSecOps 관점에 대한 생각

Shift-Left

전통적인 개발 프로세스에서 보안은 개발의 뒷부분에 등장하는데,
기능을 먼저 구현하고 테스트를 한 후, 배포 직전이 되어서야 신경을 쓴다
문제는 이 시점에서 발견된 취약점이 구조적인 수정을 요구하는 경우다.

이미 개발 단계에서 합의된 기능 명세를 다시 흔들면, 일정은 밀릴 수밖에 없고, 수정 범위도 커질테니까
DevSecOps 관점에서는 이런 패턴을 보안 부채가 쌓인 패턴이라고 한다.

그래서 이 보안 검수 단계를 개발의 초기로 Shift-Left하는 것이 DevSecOps가 주로 살펴보는 일이라고 한다.
비슷한 관점으로 rootscan이라는 툴을 개발해보고 있는데,
CI 서버에 올라가기 전에, 내 컴퓨터에서 git push를 날리는 그 순간에 잡자는 거다.

흐름을 바꾸는 "Push 차단"

rootscan은 현재 CLI 명령어 까지는 개발이 되었다.
samgrep과 trivy라는 레이어를 통과해서 보고서를 출력하게끔(필요하다면 LLM도 같이 붙고)

하지만 보통은 대충 코드를 완성하고, 습관처럼 커밋을 준비하곤 할 거다.
그 다음 과정에 rootscan을 쓰세요! 라고 해봐야 얼마나 쓰겠나....
DevSecOps는 이런 개발자의 저항과도 싸워야 한다.
그렇다면 과정에 강제성이 좀 필요하겠지.
기존 개발 흐름을 유지하면서 보안을 끼워 넣는 방법은 이렇다.

1. 열심히 코드를 짠다.
2. git commit 하고 push를 딱 누른다.
3. 그 순간 rootscan이 돌아간다.
4. 문제가 있으면 Push가 안 된다. "이거 고치고 다시 오세요."

로컬에서 끝낸다

이 도구는 무거운 서버가 필요 없다. 그냥 내 환경에서 돌면 된다.
인터넷이 끊겨도 상관없고, 서버 구축하느라 시간 쓸 필요도 없다.

• 코드 짜고,
• rootscan scan 한 번 돌려보고,
• 리포트 보고 바로 고치고.
  이렇게 "컴파일 에러 잡는 것 같은 일상적인 개발 루틴"이 되려면 무거워서도 안 되고, 복잡해서도 안 된다.

그리고 보안팀 눈치 볼 필요 없이 개발자가 스스로 통제권을 가지도록 하는 것이 목적이다.